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[57] ABSTRACT 

Disco very/layout software configures a general purp ose 
computer system to act as a management station usi ng an 
industry standard SNMP pro tocol. The discovery /layout 
software has a discovery mechanism and a layout mecha- 
nism which, in combination, permit the discovery/layout 
software to provide various submaps to a display for illus- 
trating network topology, which includes devices and device 
interconnections of the network. The submaps correspond to 
various hierarchical views of the network. Significantly, a 
persistence specification mechanism is provided in the 
discovery/layout software for specifying a submap as either 
transient (generated upon demand) or persistent (exists 
whether demanded ox not). An integrating application as 
well as the user can identify a submap as persistent. This 
feature enables better interfacing of the integrating applica- 
tion with the station, thereby providing more Mormation to 
the user. This feature further minimi yes memory require- 
ments as well as requisite processing time due to the 
elimination of unnecessary submaps and the elimination of 
processing of topology changes relative to the unnecessary 
submaps. 

13 Claims, 18 Drawing Sheets 
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PERSISTENCE SPECIFICATION SYSTEM 
AND METHOD FOR PRODUCING 
PERSISTENT AND TRANSIENT SUBMAPS IN 
A MANAGEMENT STATION FOR A DATA 
COMMUNICATION NETWORK 

FIELD OF THE INVENTION 

The present invention relates generally to data commu- 
nication networks and, more particularly, to a persistence 
specification system and method for permitting high perfor- 
mance generation of on-demand submaps in a management 
station for a data communication network. 

BACKGROUND OF THE INVENTION 

A data communications network generally includes a 
group of devices, for instance, computers, repeaters, bridges, 
routers, etc., situated at network nodes and a collection of 
communication channels for interconnecting the various 
nodes. Hardware and software associated with the network 
and particularly the devices permit the devices to exchange 
data electronically via the communication channels. 

The size of networks varies. A local area network (LAN) 
is a network of devices in close proximity, typically less than 
one mile, and usually connected by a single cable, for 
instance, a coaxial cable. A wide area network (WAN) is a 
network of devices which are separated by longer distances, 
often connected by, for example, telephone lines or satellite 
links. In fact, some WANs span the U.S. as well as the world. 
Furthermore, many of these networks are widely available 
for use by the public, including commonly universities and 
commercial industries. 

A very popular industry standard protocol for data com- 
munication along the networks is the Internet Protocol (IP). 
Tnis protocol was originally developed by the U.S. govern- 
ment's Department of Defense, and has been dedicated for 
public use by the U.S. government. In time, the Transmis- 
sion Control Protocol (TCP) and the Unreliable Datagram 
Protocol (UDP) were developed for use with the IP. The 
former protocol (TCP/IP) is a protocol which guarantees 
transfer , of data without errors, as it implements certain 
check functionality, and the latter protocol (UDP/D?) is a 
protocol which does not guarantee transfer of data, but 
requires much less overhead than the TCP/IP platform, 
Furthermore, in order to keep track of and manage the 
various devices situated on a network, the Simple Network 
Management Protocol (SNMP) was eventually developed 
for use with a UDPAP platform. The use of the foregoing 
protocols has become extensive in the industry, and numer- 
ous vendors now manufacture many types of network 
devices which can employ these protocols. 

Many management software packages ('•management 
riatforms") are presently available for implementing "man- 
agement stations" on a network, and particularly, in con- 
nection with the SNMP. Examples of commercially avail- 
able SNMP management software packages include 
OpenView from the Hewlett-Packard Company (the 
assignee herein), NetView/6000 from IBM Corp., Spectrum 
from Cabletron Systems, Inc., NetLabs/Manager from 
NetLabs, Inc., and SunNet Manager from SunConnect, Inc. 
The nodes on a network and their interconnections, often- 
times referred to as the network topology," are best dis- 
played in a graphical format, and most, if not all, of the 
available management software packages provide for this 
feature. Typically, with these packages, a network can be 
viewed from different vantage points, depending on the 
scope of the view desired. For example, one view of the 
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network could be a very wide encompassing view of all 
nodes on the entire network. A second view could be a view 
of those portions of a network within a local range, for 
example, within a particular site or building. A third view of 

3 a network, often called a segment, could be a view of the 
nodes attached to a particular LAN cable. 

Hewlett-Packard's very successful OpenView has been 
the subject of several patents, including for instance, U.S. 
Pat No. 5,185,860 issued to J. C. Wu on Feb. 9, 1993, and 

10 U.S. Pat No. 5,276,789 issued to Besaw et on Ian. 4, 1994, 
the disclosures of which are incorporated herein by refer- 
ence. U.S. Pat No. 5,185,860 describes an automatic dis- 
covery system for a management station for determining the 
network devices and interconnections of a network, or the 

5 topology. U.S. Pat No. 5,276,789 describes a graphic dis- 
play system for a management station for graphically dis- 
playing the topology of a network and provides for various 
views (including, internet, segment, and node views) that 
can be requested by a user. 

2Q Although the presently available SNMP management 
stations are meritorious to an extent, the art of SNMP 
management stations is still in a state of infancy, and the 
performance of these management stations can still be 
enhanced and optimized- A specific area where optimization 

25 is envisioned involves the integrating applications which are 
associated with the management stations and which can 
provide additional information about network devices, for 
example, routers. The additional information could include, 
for example, device configuration information, device 

* 30 status, performance parameters, additional topology 
information, etc. However, in prior art management stations, 
this additional information is oftentimes not made available 
to the user. One reason that this additional information is not 
made available is that these systems suffer from an inad- 

35 equate interface between the integrating applications and the 
display map generator within these systems. 

More specifically, many management stations have 
on-demand submap capabilities. One such example is 
Hewlett-Packard's OpenView. In on-demand submap 

40 systems, a submap corresponds with each view of the 
network to be displayed. The system map is the collection of 
all submaps. In these on-demand submap systems, and 
particularly, the OpenView system, the user specifies which 
submaps the user wishes to have available, and hence, 

45 specifies the submaps which are resident within the map. 
Moreover, the user can also open, or "explode," a submap 
during operation, even though it is not specified as resident 
in the map. In this case, the submap is generated immedi- 
ately from topology data when the user prompts the man- 

50 agement station to open the submap, hence the name 
on-demand. However, the foregoing design is problematic. 
First, if a submap is not resident in the map, and the user 
opens the submap, then an integrating application cannot 
adequately determine what additional information to pro- 

55 vide to the management station, due to time constraints in 
opening the desired submap, and the user is therefore not 
advised of this additional information. In other wards, the 
integrating applications need time to analyze the topology 
data and time to generate the additional information for 

$0 display to the user. 

Another problem with current designs is that for nonresi- 
dent submaps, integrating applications are unable to alert the 
user of critical information until the user explodes the 
submap. It is desirable to alert the user as soon as an 

65 anomaly is detected. 

Furthermore, in prior art management stations, once a 
submap has been created, it remains in the system's map 
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from then on, even if the integrating applications no longer associated with the at least one network object and having at 

need the submap. This predicament undesirably uses valu- least one segment object, at least one segment submap 

able memory space. This situation also needlessly expends associated with the at least one segment object and having 

processor time, as some events, or changes in network at least one node object, and at least one node submap 

topology, will unnecessarily be processed for updating some 5 associated with the at least one node object and having at 

of the unnecessary resident submap s. Thus, a need exists in least one interface object 

the industry for a system and method for better interfacing in accordance with a significant feature of the present 

integrating applications to an on-demand submap system, invention, the translator has a persistence specification 

for minimi ring memory requirements thereof, and for opti- mechanism The persistence specification mechanism and 

mizing performance (including speed) thereof. 10 associated methodology specify when an object to be dis- 

A¥W „ rt played is "persistent" and when an object to be displayed is 

SUMMARY OF THE INVENTION "transient" based upon inputs corresponding to the object 

An object of the present invention is to overcome the ^ in P uts are generated by the user and/or by the integrat- 

deficiencies and inadequacies of the prior art as noted above m 8 applications which are connected to the discovery/layout 

and as generally known in the industry. 15 software. The translator defines submaps as persistent when 

Another object of the present invention is to provide a m * subma P a persistent object and as transient when the 
system and method for e^ancing the performance ofa^ 

on-demand submap process in a management station. """T? con ^ uo f Y\ ^T* S ° 

r r & that integrating applications effectively have continuous 

Another object of the present invention is to provide 2 o access and can use the persistent object information to 

optimized interfacing of integrating applications with sub- pro ducc and provide additional information for the user, 

map information. Transient submaps are only generated for a temporary time 

Another object of the present invention is to provide a period when a user prompts the system, and the translator is 

system and method for nrinimizing memory requirements • configured to delete (not store) the transient submaps after 

for an on-demand submap process in a management station. 25 the user is through viewing the transient submaps. In 

Another object of the present invention is to provide a conclusion, the persistence specification system enhances 

system and method for nmumizing requisite proces sing time the interface between the integrating applications and the 

for an on-demand submap process in a management station. graphical user interface so that more information concerning 

Briefly described, the present invention is a persistence a network ^ provided to the user. The system further 

specification system and method for a management station 30 minimizes memory requirements and processing time by 

or other device of a network for enhancing an interface amoving unnecessary submaps which could be the subject 

between an integrating application and a graphical user of chan S e bascd u P° n incoming events, 

interface so that more information concerning a network is 1° addition to achieving all of the aforementioned objects, 

provided to a user, while memory requirements and pro- mc present invention has numerous other advantages, a few 

cessing time are minimized. The system comprises a pro- 35 of which are delineated hereafter. 

cessor which executes the various software elements of the An advantage of the present invention is that it is simple 

system, a discovery mechanism for deterrnining the network in design and easy to implement on a mass commercial 

topology data, and a layout mechanism for converting the scale. 

network topology data to map data and for driving a display ^ Another advantage of the present invention is that it is 

with the map data. efficient as well as reliable in operation. 

More specifically, the discovery mechanism has a net- Another advantage of the present invention is that the 

work monitor configured to monitor and determine the principles of the persistence specification system and 

topology of the network, a topology database for storing the method can be applied not only to management stations, but 

topology data, and a topology manager for managing the 45 also to other devices, including devices which do not prac- 

topology database. The network monitor is also configured rice the SNMP. 

to generate topology change events when a change in other objects, features, and advantages of the present 

network topology occurs and also to receive such events invention will become apparent to one of skill in the art upon 

from other devices connected to the network examination of the following drawings and detailed descrip- 

The layout mechanism is in communication with the 50 tion. All such additional objects, features, and advantages 

discovery mechanism and one or more integrating applica- are intended to be included herein within the scope of the 

tions. The layout mechanism has a topology-to-map present invention; 

translator, a graphical user interface (GUI), and a map nF^rRTrmnM op tup nPAwrwr* 

database. The translator is configured to convert the topol- BMEF DESCRIPTION OF THE DRAWINGS 

ogy data to the map data, to receive the events, and to change 55 The present invention can be better understood with 

the map data based upon the events. The GUI is configured reference to the following drawings taken in the context of 

to receive the map data from the translator, to manage the the text. 

map data in the map database, and to drive the display based FIG. 1 is a block diagram of a management station having 

upon the map data. The GUI also provides information to discovery/layout software which employs the persistence 

and receives information from the integrating applications 50 specification system and method of the present invention; 

concerning the map data. FIG. 2 is a schematic diagram illustrating a display map, 

In the preferred embodiment, the translator is configured which comprises a collection of submaps, any of which can 

to generate a set of hierarchically arranged submaps corre- be displayed on the display of the management station by the 

sponding with various views of the network. A map is discovery/layout software of FIG. 1; 

defined herein as the collection of all submaps. The hierar- 65 FIG. 3 is a block diagram of the discovery/layout software 

chically arranged submaps include an internet submap hav- of FIG. 1 and an integrating application interfaced therewith 

ing at least one network object, at least one network submap in accordance with the present invention; 
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FIG. 4 is a flow chart illustrating the architecture of the nodes of the network 118 discovered by the discovery/layout 

topology-to-map translator of FIG. 3; software 101. A main memory 110 within the management 

FIG. 5 is a flow chart illustrating the architecture of a read ^covery/layout software 101 The 
k ki v f prr J- discovery/layout software 101 communicates with a con- 
batch olocfc or MO. <i, ^ ventional operating system 122 and conventional network 

FIG. 6 is a flow chart illustrating the architecture of a software 124 to discover the nodes on the network 118. Hie 

retrieve objects block of FIG. 4; network software 124 serves as the intelligence, including 

FIG. 7 is a flow chart illustrating the architecture of the validation, for the data communication protocols. As shown 

compute map changes block of FIG. 4; in FIG. 1, in the preferred embodiment the network soft- 

FIG. 8 is a flow chart illustrating the architecture of a 10 ^l^^^^J^^ UDP over the IP, and 

compute submap changes block of FIG. 7; ^ 5NMP over the UDR All of the foregoing protocols are 

^ v ^ , , , well known in the art 

FIG. 9 is a flow chart illustrating the architecture of a ^ ^ coyerv/layout software 101 implements object- 
network change block of FIG 8; oriented functionality. In the context of SNMP managers, 

FIG. 10 is a flow chart illustrating the architecture of a object-oriented means that most of the management system 

segment change block of FIG. 8; 15 actions and processes that the user can invoke are oriented 

FIG. 11 is a flow chart illustrating the architecture of a toward a class of devices rather than individually managed 

node change block of FIG. 8; network nodes. 

FIGS. 12A and 12B is a flow chart illustrating the ;*? .cUscc^eryAayout sc^are 101 of ^ 1 is 

vTh, « f _ „i, ann » M^ir rt f xnr ». configured to discover the network topology, that is, all 

architecture of an interface change block of FIG. 8, 20 nctwo Vk nodes and node interconnections existing on the 

FIG. 13 is a flow chart illustrating the architecture of an nc tw 0 rk 118, and to construct a map, comprising various 

update map block of FIG. 4; submaps, any of which can be used for displaying the 

FIG. 14 is a flow chart illustrating the architecture of an network topology on the display 108. FIG. 2 shows a map 

on-demand submap block within the graphical user interface 200 which is generated by the discovery/layout software 101 

(GUI) of FIG V 25 from topology data discovered from the network 118. The 

FIG 15 is a siate diagram corresponding to a submap of discovcryAayout so^are m can enve any of the various 

. *r~r . ^ . T 6 submaps to the display 108 (FIG. 1) for viewing by the user. 

FIG 2 in accordance with the novel persistence specification ^ , ^f^v \ j "& j 

"l^ * mM . . rtf iTin 1 - The submaps in the map 200 of FIG. 2 are arranged in a 

system and method of FIG. 1, hierarchy. A root submap 202 is defined at a root level. The 

FIG. 16 is a schematic diagram of a persistence vector ^ rootsubmap 202 represents the highest logical level submap 

carespondugtoasubmaptam ^ me hierarchy and shows objects 203 acting as anchor 

specification system and method of FIG. 1; points for different submap hierarchies. Each hierarchy is a 

FIG. 17 is a flow chart illustrating the architecture of a separate management domain. This could be, for instance, a 

submap add decisional block of FIG. 7 for implementing the network, logical grouping of nodes, or some other domain, 

persistence specification system and method of FIG. 1; and 35 An internet submap 204 is defined at an internet level and is 

FIG. 18 is a flow chart illustrating the architecture of a generated by "exploding" an object 203 within the root 

persistence specification decisional block of both FIG 7 and submap 202. "Exploding" ia the context of this document 

FIG. 17 for implementing the persistence specification sys- means that the user prompts the management station 100 

tern and method of FIG. 1. with the input device 106 to break down and provide more 

4q data pertaining to the object 203 at issue. Further, the 

DETAILED DESCRIPTION OF THE internet submap 204 illustrates objects 203 in the form of 

PREFERRED EMBODIMENT networks and routers. Any one of a number of network 

The following description is of the best presently con- submaps 206 can be exploded from the internet submap 204. 

templated mode of carrying out the present invention. This Each network submap 206 shows objects 203 in the form of 

desertion is not to be taken in a limiting sense, but is made 45 segments and connectors. Any one of a number of segment 

merely for the purpose of describing the general principles submaps 208 can be exploded from an object 203 within a 

of the invention. The scope of the invention should be network submap 206. Each segment submap 208 shows 

determined by referencing the appended claims. objects in the form of network nodes. Finally, any one of a 

FIG. 1 shows a block diagram of an object-oriented number of node submaps 210 can be exploded from an 

management station 100 which is implemented with a 50 object 203 within a segment submap 208. Each node submap 

general purpose computer system containing novel 210 shows objects 203 in the form of interfaces within that 

discovery/layout software 101, which employs a persistence noa ^- 

specification mechanism 103 and associated methodology of In the preferred embodiment, although not necessary to 

the present invention. With reference to FIG. 1, the man- practice the present invention, the discovery/layout software 

agement station 100 contains a conventional processor 102. 55 101 implements on-demand submaps in order to save 

The processor 102 communicates to other elements within memory and processing time. The concept of on-demand 

the management station 100 over a system bus 104. An input submaps is to only place those submaps in the map 200 of 

device 106, for example, a keyboard or mouse, is used to FIG. 2 which the user wants to see. The netresult is that only 

input data from a user of the system 100, and a display 108 a portion of the submap hierarchy Is in the map 200 at a 

is used to output data to the user. A network interface 112 is 60 given time. In FIG. 2, submaps (nonresident) which are not 

used to interface the management station 100 to a network present, but would be created upon prompting by the user, 

118 in order to allow the management station 100 to act as are indicated by hatching. The resident submap subset of the 

a node on a network 118. A disk 114 may be used to store hierarchy will change over time as the user traverses the 

the software of the discovery/layout software 101 of the submap hierarchy and causes nonresident submaps to be 

present invention, as well as to store the databases (topology 65 created. 

and map) generated by the discovery/layout software 101. A A high level block diagram of the discovery/layout soft- 
printer 116 can be used to provide a hard copy output of the ware 101 (FIG. 1) is set forth in FIG. 3. With the exception 



11/25/2002, EAST Version: 1-03.0002 



5,689,645 

7 8 

of the persistence specification mechanism 103, the archi- take turns utilizing the combination of the operating system 

tecture of the discovery/layout software 101 in FIG. 3 is 122 (FIG. 1) and the processor 102 (FIG. 1) in order to 

essentially the same as or similar to the architecture of accomplish there respective functions. A "context switch** as 

Hewlett-Packard's well known and commercially available used herein refers to a change in control of the system 122 

management software package called Open View. As shown 5 and/or processor 102 by me foregoing software elements, 

in FIG. 3^ at a general architect level, the discovery/ The 31g ol ^ fr & 

hyout software 101 comprises a discovery mechamsm 302 p constructs the various 

for discovering nodes and interconnections of the network B i ™ X*a * ^ <*™ ™ , 

118 and a layout mechanism 304 for receiving topology data ^ubmaps 20Z-210 in the map 200 of FIG. 2. The translator 

from the discovery mechanism 302 and for generating the 318 0311 fa ™ard a request to the topology manager 310, as 

map 200 (FIG. 2) for driving the display 108. Moreover, one 10 iadicst ^ °y ^ow 320a, in order to obtain topology data 

or mare integrating applications 332 may communicate regarding particular objects. Moreover, in addition to for- 

display and map information with the layout mechanism warding topology data to the translator 318 upon request, the 

304. topology manager 310 advises the translator 318, as indi- 

The discovery mechanism 302 has a network monitor 306 cated b ? ^ 320 ^ when topology data has changed 

connected to the network 118 as indicated by connections 15 bascd u P° n an event so ^ ^ translator 318 can make any 

308* 308fc, a topology manager 310 connected to the appropriate changes m the submaps. 

network monitor 306 as indicated by arrows 312* 312fc, and ' rhe GUI 322 manages the map database 326, as indicated 

a topology database in communication with the topology DV the bidirectional arrow 328, and manages the display 108 

manager 310 as indicated by arrow 316. input device 106, as indicated by the arrows 330a, 330b. 

The network monitor 306 transmits and receives data 20 The GUI 322 receives map updates from the translator 318, 

packets to and from the network 118. The network monitor as indicated by arrow 3246, and submits user-triggered 

306 discovers and monitors network topology, as indicated events 10 translator 318, as indicated by arrow 324a. A 

by arrows 308* 3086. When network topology changes on user-triggered event includes a prompt 330a from a user to 

the network, the network monitor 306 generates events, or „ explode an object, as described relative to FIG. 2. Finally, it 

traps (SNMP vernacular), which include an object identifier snould noted ^ us ^ Na 5,276,789 to Besaw et al., 

and object change information. The network monitor 306 which . is incorporated herein by reference, describes a 

can also receive events from other devices, such as a router, graphical user interface which could be employed to imple- 

in the network 118. The network monitor 306 interacts with mcnt mc GUI 322 herein. 

the network 118 by way of the network software 124 (FIG. 3Q FIG. 4 shows a flow chart 400 indicating the architecture 

1), which essentially comprises protocol stacks, correspond- and functionality of the preferred embodiment of the 

ing to IP, TCP, UDP, and SNMP in the preferred topology-to-map translator 318 (FIG. 3). The translator 

embodiment, and which generally implements these proto- employs the persistence specification mechanism 103 and 

cols and performs validation functions. Furthermore, the associated methodology in accordance with the present 

network monitor 306 populates the topology database 314 35 invention, which minimize context switches (changes in the 

by way of the topology manager 310 and notifies the control of the operating system 122 and/or processor 102) 

topology manager 310 of events (topology changes). Finally, and significantly enhance the speed and performance of the 

it should be noted that U.S. Pat, No. 5,185,860 to Wu, which discovery/layout software 101. 

is incorporated herein by reference, describes a node dis- With reference to FIG. 4, initially, events are queued and 

covery system which could be employed to implement the ^ accumulated in a queue (not shown), or accumulator, asso- 

network monitor 306 herein. dated with the topology manager 310, and await retrieval by 

The topology manager 310 manages the topology data- the translator 318. The translator 318 reads a batch of events 

base 314, as indicated by . bidirectional arrow 316. The from the topology manager 310 during each access. Each 

topology manager 310 prompts the network monitor 306 to event contains an object identifier and an object change, 

update topology data related to particular events, as indi- 43 Moreover, the batch is any number of events greater than 

cated by arrow 312* and receives topology updates, as zero. In the tested embodiment, the batch was limited to a 

indicated by arrow 3126. number no greater than 500 events, but other settings, either 

The topology database 314 stores topology data based ^ css ox greater than (perhaps significantly) this number 

upon objects, which are used to partition the network for could be utilized, depending upon the configuration of the 

logical reasons. Objects include, for example but not limited 50 s y stenL 

to, a network, a segment, a computer, a router, a repeater, a Next, as indicated in block 404, the translator 318 calls the 

bridge, etc. Moreover, the topology data stored with respect topology manager 310 for a list of topology data regarding 

to the objects includes, for example but not limited to, an all objects which were identified in the events. After receiv- 

interface or device address, an interface or device type, an ing the topology data, block 404 transfers to block 406. 

interface or device manufacturer, and whether an interface 55 At block 406, the translator 318 computes the changes to 

or device supports the SNMP. be made to the map data, particularly the map 200 (FIG. 2), 

The layout mechanism 304 has a topology-to-map trans- based upon the topology data changes indicated in the 

lator 318 in communication with the topology manager 310 events. Block 406 transfers to block 408. 

as indicated by arrows 320* a graphical user interface At block 408, the translator 318 updates the map 200 

(GUI) 322 in communication with the topology-to-map 60 (FIG. 2) by calling the GUI 322 and advising the GUI 322 

translator 318 as indicated by arrows 324* 324fr, and a map 0 f all submap changes (SYMCHANGELIST and 

database 326 in communication with the GUI 322 as indi- NEWSYMUST described hereinafter) pertaining to all 

cated by bidirectional arrow 328. The integrating application object changes. This transaction is preferably, although not 

332 communicates information with the GUI 322, as indi- necessarily, a batch transfer. During this batch transfer 

cated by arrows 333* 333*. 6 5 transaction, the translator 318 identifies each submap to be 

It should be noted that the network monitor 306, the changed, each object to be changed within a submap, and the 

topology manager 310, the translator 318, and the GUI 322 particular change to be effectuated to the object. An object 
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change may include, for example but not limited to, a color, to service another record. If not, then the block 610 transfers 

position, or connection change. Block 408 transfers to block to block 612, which sends a request to the topology manager 

4X0 310 for a batch transfer of object information pertaining to 

At block 410, the translator 318 dctennincs whether there ^Tl^^f 

-I . , . r , . . . „ . r i^^,, 5 of the architecture and functionality of a preferred embodi- 

xs anotha batch of events , ^ m f 1 ^ 0 ^ 5 ment of the compute map changes block 406 (FIG. 4). In this 

manager 310. If so then block 410 transfers ito Wock402 flow ^to^^dtiamte* which submaps (FIG. 2) 

and the previously described process is repeated. If not, then m chan ^ md the change to be effectuated, based upon the 

the software waits at block 410 for another batch of events. object ^^0^ the object changes, which were pre- 

Because of the preferred embodiment of the translator 318 viously determined based upon the events. With reference to 
set forth in FIG. 4, topology data pertaining to various 10 FIG. 7, block 701 initiates an object change counter so that 
objects is retrieved in a batch from the topology manager all object changes are considered. Block 701 transfers to 
310 and, furthermore, map data pertaining to various sub- block 702. Block 702 determines a submap identifier based 
maps is transferred in a batch from the translator 318 to the upon which of the submaps (FIG. 2) are affected by the 
GUI 322. The foregoing implementation minimizes context object change which is presently at issue. Block 702 trans- 
switches, i.e., nunimizes the number of times that control of 15 fers to block 704, which determines whether the affected 
the processor 102 (FIG. 1) and/or the operating system 122 submap exists. If the submap does exist then the block 704 
(FIG. 1) is passed from one software module to another. transfers to the block 710. If the submap does not exist, then 

FIG. 5 shows a flow chart of the aremtecture and tunc- the block 704 transfers to the block 705. At block 705, a 

tionality for implementing a preferred embodiment of the ^ determination is made as to whether the submap at issue 

read batch block 402 (FIG. 4). This flow chart illustrates should be created based upon the persistence specification of 

how the translator 318 reads a batch of events from the the present invention, i.e., whether the submap contains 

topology manager 310. As indicated in a block 502, initially, persistent obj ects. The persistence specification will be more 

events from the topology manager 310 which indicate fully described relative to FIGS. 15 through 18 hereinafter 

changes in topology data are accumulated (queued). A ^ (particularly, FIG. 17 is a flow chart illustrating the specific 

counter at block 504 is used in connection with a loop in architecture of block 705). If the submap is not to be added, 

order to route each event from the topology manager 310 to then the block 705 transfers to block 716. If the submap is 

the translator 318. At block 506, an event is read by the to be added, then block 705 transfers to block 706, which 

translator 318 from the manager 310. Block 506 transfers to creates the affected submap in the map 200 (FIG, 2). Block 

block 508, which decodes the event The event is decoded to 3Q 706 transfers to block 708. 

identify the type of event and associated data. There are At block 708, the translator 318 populates the newly 

numerous types of events, and different types of events will created submap with map data retrieved from the topology 

have different types of associated data. More specifically, an database 326. Next, at block 710, submap changes based 

event can involve, for example but not limited to, a new upon the current event, particularly the object identifier and 

node or a node status change (e.g,, connected/accessible or 33 the object change, are computed. These computations of 

connccted/unacccssible). An event has an event identifier, block 710 will be described hereinafter relative to FIG. 8. 

usually at the header, for identifying the type of event Block 710 transfers to block 712, which makes a determi- 

Moreover, in the case of a new node, the event will contain nation as to whether the object at issue meets the novel 

an object identifier and an address. In the case of a node persistence specification. Again, the persistence specifica- 

status change, the event will contain an object identifier, the ^ don will be more fully described hereinafter relative to 

old status, and the new status, FIGS. 15 through 18 (particularly, FIG. 18 is a flow chart 

Block 508 transfers to block 510. At block 510, the illustrating the specific architecture of block 712). If the 

decoded event data (Le„ a record) is added to a TUST. At object meets the persistence specification, then block 712 

block 512, the counter is incremented so that another event transfers to block 714, which identifies the submap at issue 

is serviced. Block 512 transfers to block 514, which deter- 45 as persistent, and then block 714 transfers to block 716. If 

mines whether there are any more events to be serviced. If the object does not meet the persistence specification, then 

so, then block 514 transfers back to block 506 and the block 712 transfers to block 716. 

aforementioned process is repeated. If not, then block 514 At block 716, the object change counter is incremented so 

returns to block 404 (FIG. 4). that another object change is considered with respect to the 

FIG. 6 shows a flow chart of the architecture and tunc- 50 submaps. Block 716 transfers to block 718, which makes a 

tionality of a preferred embodiment for implementing the determination as to whether any object changes remain to be 

retrieve object information block 404 (FIG. 4). As indicated serviced. If so, then block 718 transfers back to block 702. 

in FIG. 6, in this flow chart, object information (OBJINFO) * not > men *° fiow chart tenninates after block 718. 

is decoded from the decoded event data contained in the Hence, at the conclusion of the operation of the logic in 

TUST. At block 602, the TUST is read. Block 602 transfers 55 HCL 7, a batch of submap identifiers with associated submap 

to block 604, which initiates an event counter. The counter changes has been generated from a batch of object identifiers 

in connection with a loop causes all of the events within the with associated object changes. 

TUST to be serviced. In the loop, at block 606, a single With reference to FIG. 8, relative to the submap change 
record is read. From the record, (a) an object identifier and computations of block 710 (FIG. 7), block 804 retrieves data 
(b) an object change are determined. The foregoing data is 60 concerning a single object from OBJUST. Block 804 trans- 
placed in an object list (OBJUST). Next, at block 608, the fers to block 806, which determines whether the object type 
counter is incremented so that another record of TUST is is a network If so, then block 806 transfers to block 808 
serviced, if any remain. Block 608 transfers to block 610. At (flow chart in FIG. 9), which computes the submap changes, 
block 610, it is determined whether there are any events left and then block 808 transfers to block 822. If not, then the 
to be serviced by comparing the record count of the record 65 block 806 transfers to the block 810. 
counter to the total number of records already processed. If At block 810, a determination is made as to whether the 
so, then block 610 transfers back to block 606, which begins object type is a segment If so, then the block 810 transfers 
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to the block 812 (flow chart of FIG. 10), which computes the 
segment changes to the submaps, and then block 812 trans- 
fers to block 822. If not, then the block 810 transfers to the 
block 814. 

At block 814, a determination is made as to whether the 
object type is a node. If so, then the block 814 transfers to 
the block 816 (flow chart of FIG. 11), which computes the 
node changes for the submaps, and then block 816 transfers 
to block 822. If not, then the block 814 transfers to the block 
818. 

At block 818, a determination is made as to whether the 
object type is an interface. If so, then the block 818 transfers 
to the block 820 (flow chart of FIG. 12), which computes the 
interface changes to the submap, and then block 820 trans- 
fers to block 822. If not, then the flow chart terminates. 

FIG. 9 shows a flow chart of the architecture and func- 
tionality of a preferred embodiment for implementing the 
network change block 808 (FIG. 8). This flow chart com- 
putes changes to the internet submap 204 (FIG. 2), which 
displays the networks. Moreover, note that there is only a 
single submap (multiple submaps are possible) at the inter- 
net level in the preferred embodiment With reference to 
FIG. 9, at block 902, a variable INET is set to assume the 
contents of the internet submap 204 (FIG. 2). The contents 
include a list of network objects and router objects and a list 
of connections between the network and router objects. 
Block 902 transfers to block 904. At block 904, a variable 
NETOBJ is set to assume the value of the object identifier 
(OBJID). The 0BJID is retrieved from the OBJINFO. Block 
904 transfers to block 906. At block 906, a determination is 
made as to whether NETOBJ is in INET, i.e., whether the 
object to be changed resides within the internet submap 204 
(FIG. 2). If so, then the block 906 transfers to the block 908, 
which adds the network pertaining to the NETOBJ to a list 
SYMCHANGRI 1ST. If not, then the block 906 transfers to 
the block 910, which adds the network pertaining to the 
NETOBJ to a list NEWSYMUST. The lists SYM- 
CHANGELTST and NEWSYMUST are ultimately for- 
warded by the translator 318 to the GUI 322 during the batch 
transfer therebetween. 

FIG. 10 shows a flow chart of the architecture and 
functionality of a preferred embodiment for implementing 
the segment change block 812 (FIG. 8). In this flow chart, 
segment changes are determined and computed. With ref- 
erence to FIG. 10, block 1002 sets a variable INET to 
assume the contents of the internet submap 204 (FIG. 2). 
The contents include a list of network and router objects and 
a list of connections between the network and router objects. 
Block 1002 transfers to block 1004. At block 1004, a 
variable SEGOBJ is set to assume the current object iden- 
tifier (OBJID), which is retrieved from the object informa- 
tion (OBJINFO). Block 1004 transfers to block 1006. At 
block 1006, a variable NETOBJ is set to the network 
identified (NETID), which is determined from the 
OBJINFO. Block 1006 transfers to block 1008. At block 
1008, a determination is made as to whether NETOBJ is In 
INET, Le., whether the current network is within the current 
internet submap 204 (FIG. 2). If not, then the flow chart of 
FIG. 10 tenninates. If so, men the block 1008 transfers to 
block 1010. At block 1010, a variable NET is set to assume 
the contents of the network submap 206 (FIG. 2) pertaining 
to NETOBJ. The contents include, far example but not 
limited to, a list of segment and connector objects and 
connections between segment and connectors. Block 1010 
transfers to block 1012. At block 1012, a determination is 
made as to whether SEGOBJ is in the NET (i.e., is the 
segment in the network submap?). If so, then the block 1012 
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transfers to the block 1014, which adds the segment per- 
taining to SEGOBJ to the SYMCHANGEUST. Otherwise, 
if not, block 1012 transfers to the block 1016, which adds the 
segment pertaining to SEGOBJ to NEWSYMUST. Finally, 
5 after blocks 1014, 1016. the flow chart of FIG. 10 terminates 
and operation transfers back to FIG. 8. 

FIG. 11 shows a flow chart of the architecture and 
functionality of a preferred embodiment for implementing 
the node change block 816 (FIG. 8). In the flow chart of FIG. 
10 11, node changes are ctetermined and computed by the 
translator 318. As shown in FIG. 11, block 1102 sets a 
variable INET to assume the contents of the internet submap 
204 (FIG. 2). The contents include a list of network and 
router objects and a list of connections between the network 
and router objects. Block 1102 transfers to block 1104. At 
15 block 1104, a variable NODEOBJ is set to assume the object 
identifier (OBJID) contained in the object information 
(OBJINFO). Block 1104 transfers to block 1106. At block 
1106, a variable SEGOBJ is set to assume the segment 
identifier (SEGID) contained within the OBJINFO. Block 
20 H06 transfers to block 1108. At block 1108, a variable 
NETOBJ is set to assume the network identifier (NETID) 
contained within the OBJINFO. Block 1108 transfers to 
block 1110. At block 1110, a determination is made as to 
whether NETOBJ is in INET (ic, is the network in the 
25 internet submap?). If not, then the flow chart terminates. If 
so, then the block 1110 transfers to the block 1112. At block 
1112, the variable NET is set to assume the contents of the 
network submap 206 (FIG. 2) pertaining to NETOBJ. The 
contents include, for example but not limited to, a list of 
30 segments, connectors and connections between segments 
and connectors. Block 1112 transfers to block 1114. At block 
1114, a determination is made as to whether SEGOBJ is in 
NET. If not, then the flow chart terminates. If so, then the 
block 1114 transfers to the block 1116. At block 1116, the 
35 variable SEG is set to assume the contents of the segment 
submap 208 (FIG. 2) pertaining to SEGOBJ. The contents 
include, for example but not limited to, a list of nodes and 
connections between the nodes and the network. Block 1116 
transfers to block 1118. At block 1118, a determination is 
40 made as to whether NODEOBJ is in SEG, i.e., whether the 
node object is in the present segment at issue. If so, then the 
block 1118 transfers to the block 1120, which adds the node 
pertaining to NODEOBJ to SYMCHANGEUST and then 
the flow chart terminates. Otherwise, if not, the block 1118 
45 transfers to the block 1122 which adds the node pertaining 
to NODEOBJ to NEWSYMUST and then the flow chart 
terminates. 

FIGS. 12A through 12C collectively show a flow chart of 
the architecture and functionality of the preferred embodi- 
50 ment for implementing the interface change block 820 (FIG. 
8). In this flow chart, interface changes in the submaps are 
determined and computed by the translator 318 (FIG. 3). 
With reference to FIG, 12A, a block 1202 sets a variable 
INET to assume the contents of the internet submap 204 
55 (FIG. 2) which is currently at issue. The contents include a 
list of nets, routers and connections objects. Block 1202 
transfers to block 1204. At block 1204, a variable IFOBJ is 
set to assume the OBJID contained within the OBJINFO. 
The block i204 transfers to the block 1206. At block 1206, 
60 the variable NODEOBJ is set to assume the NODEID 
contained within the OBJINFO. Block 1206 transfers to 
block 1208. At block 1208, the variable SEGOBJ is set to 
assume the SEGID contained within OBJINFO. Block 1208 
transfers to block 1210. At block 1210, a variable NETOBJ 
is set to assume the NEITD contained within OBJINFO. 
After block 1210, the initialization process has been com- 
pleted and the block 1210 transfers to block 1212. 



11/25/2002, EAST Version: 1.03.0002 



5,689,645 

13 14 

At block 1212, a determination is made as to whether interface pertaining to IFOBJ is added to 

NETOBJ is in INET, Le., whether the network object is in SYMCHANGEUST, as indicated at block 1250. If not, then 

the current internet submap 204 (FIG. 2). If not, the Sow the block 1248 transfers to the block 1252, which adds the 

chart terminates, as shown in Kg. 12A. If so, then block interface pertaining to IFOBJ to NEWSYMUST. Finally, 

1212 transfers to block 1214. At block 1214, a determination 5 after blocks 1250, 1252, the flow chart contained coliec- 

is made as to whether NODEOBJ is in INET, Le., whether tively in FIGS. 12A through 12C terminates, 

the node object is in the internet submap 204 (FIG. 2). If not, fig. 13 shows a flow chart of the architecture and 

then the block 1214 transfers to the block 1222. If so, then functionality of a preferred embodiment for implementing 

the block 1214 transfers to the block 1216. the update map block 408 (FIG. 4). In this flow chart, a batch 

At block 1216, a determination is made as to whether 10 transfer of changes is sent by the translator 318 to the GUI 

IFOBJ is in INET. If so, then the block 1216 transfers to the 322. With reference to FIG. 13, at block 1302, the translator 

block 1218, which adds the interface pertaining to IFOBJ to 318 transfers the NEWSYMLJST to the GUI 322, and in 

the SYMCHANGEUST. If not, then the block 1216 trans- block 1304, the translator 318 transfers the SYMCHANGE- 

fers to block 1220, which adds the interface pertaining to LIST to the GUI 322. After block 1304, the flow chart of 

IFOBJ (between node object and network object) to 15 FIG. 13 terminates and the operation passes back to block 

NEWSYMUST. 410 (FIG. 4). 

At block 1222, the variable NET is set to assume the FIG. 14 illustrates an on-demand submap module con- 
contents of the network submap 206 (FIG. 2). The contents tained within the GUI 322 (FIG. 3). This flow chart imple- 
include, for example but not limited to, segments, ments the user interface to the various submaps of the map 
connectors, connections, etc. Block 1222 transfers to block 20 200 (FIG. 2). With reference to FIG. 14, at a block 1402, the 
1224 of FIG. 12B. GUI 322 monitors the input devices connected to the man- 

At block 1224, a determination is made as to whether agement station 100 (FIG. 1), for instance, the keyboard 

SEGOBJ is in NET, Le., whether the segment object is 106. When the user of the management station 100 prompts 

within the network submap 206 (FIG. 2). If not, then the the management station 100 via the keyboard 106 or via 

flow chart terminates. If so, then the block 1224 transfers to some other input device to explode an object on the display 

the block 1226 108 > me block 1402 of 14 transfers to the block 1404 

At block 1226, a determination is made as to whether ord f J? P»*« «« ™« ?&** M * 404 ' . a 

NODEOBJ is in NET, i.e., whether the node object is within ^^f™ 18 S *^P v 

__, v „„i -in* ran i\ ™ ti* a™ „h„*+ contained within the map 200 (FIG. 2). If so, then the block 

the network submap 206 (FIG. 2). If not, then the flow chart 30 -. Ajt(k _ - t ^ /TT, -. A \, r ~ ' V. - ~ AAA 

t . _ - . - JL^ T \ _ r, , t t^,.^ 1404 transfers to the block 1408. If not, then the block 1404 

transfers to block 1234. If so. then the block 1226 transfers _ £ ^ . , , , . . _ . ... ' . . ^ . 

to block 122S transfers to the block 1406, which creates and populates the 

... submap. The GUI 322 populates the submap by requesting 

At block 1228, a determination is made as to whether the 318 to create and populate a submap based on 

IFOBJ is within NET, Le., whether the interface object is topology data retri eved from topology manager 310. 

within the network submap 206 (FIG. 2). If so, then the 35 Mareover ^ blDck U06 transfers to block 1408 which opens 

block 1228 transfers to the block 1230, which adds the ^ cMd su5map ^ delays the child submap on the 

interface pertaining to IFOBJ to SYMCHANGEUST. If not, display 108 forSeusex 
then the block 1228 transfers to the block 1232, which adds 

the interface pertaining to IFOBJ (which is between a node PERSISTENCE SPECIFICATION 

object and a segment object) to NEWSYMUST. The blocks 40 _ c .„ ^ J . 

1230, 1232 transfer to the block 1234. ^ concc P t of o^mand submaps, as illustrated in and 

. . 1 , ^ . . , 0 ™ . ^ described with respect to FIG. 2, is to only place those 

At block 1234, the vanable STO« set to assume the sub in(hc ^0(^0.2) which the userwanteto sec 

contents of the segment submap 208 FIG J). Tta : contents qu ^ u ^fa^ 1} ^ mc j^ lcnlC ntation rf roc 

hclude, for example but not hmited . * s nodes ; and coimec- ^ mechanism i 03 (FIG. 1) herein, 

tions to network (mterfaces). Block 1234 transfers to block « amcept fa extended to include submaps needed by 

b integrating applications 332 (FIG. 3), which can dynami- 

At block 1236, a determination is made as to whether ca u y change during operation. The net result is that only a 

NODEOBJ is in SEG, i.e. t whether the node object is within portion of the submap hierarchy is in the map 200 (FIG. 2) 

the segment submap 208 (FIG. 2). If not, then the flow chart ^ at a g£ ven timef and fa G information provided to the user is 

transfers to the block 1246 of FIG. 12B. If so, then the block significantly enhanced by permitting integrating applica- 

1236 transfers to the block 1238. ti ons 332 to supplement device configuration information 

At block 1238, a determination is made as to whether which has been discovered from the network 118 by the 
IFOBJ is within SEG, i.e., whether the interface object is discovery mechanism 302 (FIG. 3). 
within the segment submap 208 (FIG. 2). If so, then the 55 The persistence specification involves defining each sub- 
block 1238 transfers to the block 1242, which adds the map of the map 200 (FIG. 2) as cither persistent or transient, 
interface pertaining to IFOBJ to SYMCHANGEUST. If not, ^ indicated in the diagram 1500 of FIG. 15. No matter what 
then the block 1238 transfers to the block 1244, which adds £ S specified by the persistence specification, the user still has 
the interface pertaining to IFOBJ to NEWSYMLJST. The access to the entire topology through the map 200. However, 
blocks 1242, 1244 transfer to the block 1246 of FIG. 12C. w those submaps which are designated as persistent are placed 

At block 1246, the variable NODE is set to assume the on the map 200 immediately after this determination, and 

contents of the node submap 210 (FIG. 2). The contents those submaps which are designated as transient are only 

include interface objects. Block 1246 transfers to block created on demand after a user request, and then when the 

1248. user leaves the transient submap, the transient submap is 

At block 1248, a determination is made as to whether 65 removed from the map 200 (FIG. 2). 

IFOBJ is within NODE, Le., whether the interface object is The persistence specification is useful when there is an 

within the node submap 210 (FIG. 2). If so, then the integrating application 332 (FIG. 3) which is tightly inte- 
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grated with the submap hierarchy. In other words, it is useful tal information which can be provided by the integrating 

where the integrating application 332 depends on the trans- applications 332. A field identifies some parameter of an 

lator 318 to place certain objects in the map 200 in order for object (for example but not limited to, vendor 

the integrating application 332 to operate properly. For (manufacturer), device type, address, rate (e.g., packets/ 

example, a company may have developed an integrating 5 second), etc.). The value is simply a value for that field (for 

application 332 which adds a blob symbol to a router in a example but not limited to, CISCO, router, 15,2.112.227, 55 

node submap and needs the status of the blobs to propagate packets/second, etc.). So, for a vendor field, possible values 

up the submap hierarchy. Accordingly, the integrating appli- are, for instance, Hewlett-Packard, CISCO, International 

cation 332 would need the router specified in the persistence Business Machines (IBM), etc. For a device type possible 

specification. to values are, for example, a router, a printer, etc. 

In order to implement the persistence specification, a Furthermore, block 1802 transfers to block 1804, which 

persistence vector 1600 of FIG. 16 is associated with each initiates a counter for the purpose of considering all of 

of the suhmaps of the map 200 (FIG. 2) by the GUI 322 pairings of fields and values with respect to the object at 

(FIG. 3). The persistence vector 1600 comprises numerous issue. Block 1804 transfers into the loop which begins with 

persistence bits. A persistence bit b„ corresponds to the user 15 block 1806. 

of the computer system 100 and is generated by the GUI At block 1806, a variable EXPR is set to assume a field 

322. Moreover, there is provided a persistence bit b A1 . . . b^ and a value. Block 1806 transfers to Mock 1808, which sets 

corresponding with each of the integrating applications 332 a variable EXPRVAL to assume the value (EXPR*VALUE) 

(FIG. 3) that is associated with the discovery/layout soft- within the variable EXPR- Block 1808 transfers to block 

ware 101 (FIGS. 1, 3). In order for a submap to be consid- 20 1810. 

ered transient, none of the persistent bits b u , b A1 . . . b^ in At block 1810, a variable OBJVAL is set to assume the 

the persistence vector 1600 must be asserted. Conversely, object value pertaining to the object at issue within the 

when any of the bits b H , b Al . . , b^ of the persistence vector particular field (EXFR'FIELD) of EXPR. Block 1810 traus- 

1600 is asserted, then the respective submap is considered to Mock 1812. 

persistent 25 At block 1812, OBJVAL is compared to EXPRVAL, i.e., 

Referring back to the state diagram in FIG. 15, a submap the object value is compared to the integrating application 

transitions from transient to persistent in the following value or test value. If the object value does not match the 

circumstances: (a) the user or an integrating application 332 integrating application value, then the object does not meet 

makes a change (for example, adding a background graphic, the persistent specification, as indicated at block 1814 and 

moving a symbol, changing a symbol label, changing to auto 30 the flow chart terminates. However, if the object value 

or manual layout, or hiding a symbol) with respect to an matches all of the integrating application values, then the 

object and the change does not affect anything stored in the object is ultimately made persistent at block 1820. However, 

topology database 314; or (b) an integrating application Ai before reaching block 1820, block 1812 transfers to block 

asserts its corresponding persistence bit b Ai . A submap 1816, which increments (he counter initiated in block 1804. 

changes from the persistent state to the transient state when 35 Moreover, block 1816 transfers to block 1818, which dcter- 

an integrating application de asserts its corresponding, per- mines whether all EXPRs have been considered. If some 

sistence bit, if this results in all persistence bits of the remain, then block 1818 transfers back to block 1806 and the 

persistence vector 1600 being deasserted. Thus, in foregoing process continues. If no more EXPRs remain, then 

conclusion, a user can create a persistent submap, whereas the flow chart transfers to block 1820, which specifies the 

an integrating application can create either a persistent or a 40 object as meeting the persistence specification and then the 

transient submap. flow chart terminates. 

Recall that in FIG. 7, block 705 makes an inquiry as to When an object is definitively matched to a field/value 

whether the submap at issue should be added to the map 200 pair and designated persistent, the translator 103 advises the 

(FIG. 2) based upon the persistence specification. FIG. 17 is 45 GUI 322 of this fact, and then the GUI 322 informs the 

a flow chart illustrating the architecture and functionality of integrating application 332 of the existence of the persistent 

a preferred embodiment of block 705. As shown in FIG. 17 object In turn, the GUI 322 provides supplemental 

at block 1702, a variable OBJINFOis set to assume each of information, as indicated by arrow 333£>, pertaining to 

the object identifiers within the submap, and each of the and/or based upon the persistent object to the GUI 322 for 

object identifiers is considered via a counter. Block 1702 50 introduction into the appropriate submaps and for display, 

transfers to block 1704. It will be obvious to those skilled in the art that many 

At block 1704, a determination is made as to whether the modifications can be made to the preferred embodiment as 

particular object at issue meets the persistence specification. described above without departing from the spirit and scope 

If not, then block 1704 transfers to block 712 (FIG. 7). If so, of the present invention. The disclosures and description are 

then the block 1704 transfers to the block 1706, which 55 intended to be illustrative and any such modifications are 

defines the submap containing the object as a persistent intended to be included herein within the scope of the 

submap by asserting the persistence bit (one of b„, b Al . . . present invention, as is defined in the following claims. 

b^J corresponding with the submap at issue. Block 1706 Wherefore, the following is claimed: 

then transfers to block 706 (FIG. 7). 1. A persistence specification system, comprising: 

FIG. 18 shows a flow chart far determining whether an 60 a processor, 

object should be classified as either persistent or transient, as a discovery mechanism associated with a processor, said 

is determined in block 712 (FIG. 7) and also in block 1704 discovery mechanism configured to generate and store 

(FIG. 17). Referring to FIG. 18, a block 1802 sets a variable topology data specifying devices and interconnections 

FILTEREXPR to assume a list of fields and values, which of a network; and 

are transferred from the translator 103 to the integrating 65 a layout mechanism associated with said processor and 

application 322. The fields and values are essentially flags interfaced with said discovery mechanism, said layout 

for the integrating applications 332 and identify supplemen- mechanism configured to receive said topology data 
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from said discovery mechanism, said layout mecha- 
nism configured to drive a display based upon said 
topology data, said layout mechanism comprising: 
a translator configured to convert said topology data to 
v map data, said translator having a presistepce speci- 
fication means, saia persistence specification mea ns 
fox specifying based upon a persistence input w hen 
a n object to be displayed is persistent a nd, 
alternatively, when said object is transient , sai d per- 
sistence sp education means for delming said ma p 
d ata as pe rsist ent when said map data has a persiste nt 
object and tor defining said map data as transient 
when said map data is without a persistent object, 
said translator configured to generate and continu- 
ously maintain said persistent map data and config- 
ured to generate and temporarily maintain transient 
data during a temporary time period corresponding 
to a demand bv a user; an d 
a graphical user interface configured to receive said 
map data from said translator and to drive said 20 
display based upon said map data; 
an integrating application in communication with said 
persistence specification mechanism for generating 
said persistence input; 
said persistent specification mechanism being configured 25 
to advise said integrating application of said persistent 
objects; and 

said integrating application being configured to provide 
supplemental display information to said graphical user 
interface based upon said persistent objects. 

2. The system of claim 1, wherein said persistence input 
is generated by an integrating application. 

3. The system of claim 1, wherein said persistence input 
is produced by said user. 

4. The system of claim 1, wherein said translator is 
configured to generate a plurality of hierarchically arranged 
submaps from said topology data. 

5. The system of claim 4, wherein said hierarchically 
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evaluation an persistence input pertaining to said 
objects, said, persistence mechanism configured to 
evaluate each said submap and configured to specify a 
submap as persistent and, alternatively, as transient, 
. based upon said submap evaluation, said submap being 
specified as persistent when said submap comprise a 
persistent object, said submap being specified as tran- 
sient when said submap comprises no persistent object; 
and 

said translator configured to generate and continuously 
maintain said persistent submaps within said map 
database, said translator configured to generate and 
temporarily maintain said transient submaps upon 
receiving a user prompt for a temporary time period 
corresponding with said user prompt; 

said integrating application in communication with said 
persistence specification mechanism for generating 
said persistence input: 

said persistence specification mechanism being config- 
ured to advise said integrating application of said 
persistent objects; and 

said integrating application being configured to provide 
supplemental display information to said graphical user 
interface based upon said persistent objects. 

7. The system of claim 6, wherein said persistence input 
is generated by an integrating application. 

8. The system of claim 6, wherein said persistence input 
is produced by said user. 

9. The system of claim 6, wherein said persistence input 
defines a vendor. 

10. Hie system of claim 6, wherein said persistence input 
defines a device type. 

11. The system of claim 6, wherein said translator is 
configured to generate a plurality of hierarchically arranged 
submaps from said topology data. 

12. The system of claim 11, wherein said hierarchically 
arranged submaps include an internet submap having at least 



arranged submaps include an internet submap having at least 40 one network object, at least one network submap associated 



one network object, at least one network submap associated 
with said at least one network object and having at least one 
segment object, at least one segment submap associated with 
said at least one segment object and having at least one node 45 
object, and at least one node submap associated with said at 
least one node object and having at least one interface 
object 

6. A persistence specification system for enhancing inter- 
communication between an integrating application and a 50 
graphical user interface so that more information concerning 
a network is provided to a user, while memory requirements 
and processing time are minimized, comprising: 
a topology database for storing a plurality of submaps of 55 
map data far a graphical user interface, said submaps 
for driving a display; 
a translator configured to convert said topology data from 
said topology database to map data for said map 
database, said translator configured to generate sub- 50 
maps from said map data for said graphical user 
interface for driving said display; 
a persistence specification mechanism associated with 
said translator, said persistence specification mecha- 
nism configured to evaluate objects within said map 65 
data and configured to specify each object as persistent 
and, alternatively, as transient, based upon said object 



with said at least one network object and having at least one 
segment object, at least one segment submap associated with 
said at least one segment object and having at least one node 
object, and at least one node submap associated with said at 
least one node object and having at least one interface 
object 

13. A computer readable medium having a program for 
enhancing intercommunication between an integrating 
application and a graphical user interface so that more 
information concerning a network is provided to a user, 
comprising: 

a topology database for storing topology data pertaining 
to devices and device interconnections of said network; 

a map database far storing a plurality of submaps of map 
data far a graphical user interface, said submaps for 
driving a display; 

a translator configured to convert said topology data from 
said topology database to map data for said map 
database, said translator configured to generate sub- 
maps from said map data for said graphical user 
interface for driving said display; 

a persistence specification mechanism associated with 
said translator, said persistence specification mecha- 
nism configured to evaluate objects within said map 
data and configured to specify each object as persistent 
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and, alternatively, as transient, based upon said object 
evaluation and a persistence input pertaining to said 
objects, said persistence mechanism configured to 
evaluate each said submap and configured to specify a 
submap as persistent and, alternatively, as transient, 5 
based upon said submap evaluation, said submap being 
specified as persistent when said submap comprises a 
persistent object, said submap being specified as tran- 
sient when said submap comprises no persistent object; 
and 10 
said translator configured to generate and continuously 
maintain said persistent submap s within said map 
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database, said translator configured to generate and 
temporarily maintain said transient submaps upon 
receiving a user prompt for a temporary time period 
corresponding with said user prompt; 

said integrating application in communication with said 
persistence specification mechanism for generating 
said persistence input; 

said persistent specification mechanism being configured 
to provide supplemental information to said graphical 
user interface based upon said persistent objects. 
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